Identifying network rotuters and paths

ABSTRACT

A network-wide set of paths potentially taken by packets in a communications network is identified by collecting packets containing information indicative of the interconnection of the network, and of its interconnection with other networks. The contents of the collected packets are used to identify the network-wide set of routers and sub-networks and their interconnections, which are traversed by communications within the network. An output is provided that is indicative of any selected part of the network-wide set of routers and sub-networks and their interconnections.

TECHNICAL FIELD

This invention relates to methods and apparatus for identifying routers,the associated interconnecting communications links and the paths takenby packets traversing those links in a communications network, such as apacket network using the Internet Protocol (IP). The invention isparticularly applicable to networks that use link-state routingprotocols such as Open Shortest Path First (OSPF) or Intermediatesystem-Intermediate system (IS-IS), or any equivalent thereof.

BACKGROUND ART

In order to distinguish themselves from their competitors and improvelevels of service to customers without compromising existing coststructures or capital budgets, Internet service providers (ISPs) areincreasingly employing cost optimisation, service enhancement or servicedifferentiation mechanisms to implement “traffic management” withintheir networks. These mechanisms include traffic engineering (describedbelow), quality of service (QoS) measurements and service levelagreements (SLAs). There are a variety of technologies that can helpoperators implement these “traffic-managed” networks. In the case of IPnetworks these include Multi-Protocol Label Switching (MPLS), see forexample Request for Comments (RFC) 3031 of the Internet Engineering TaskForce, and Differentiated Services, see for example RFCs 2474 and 2475.

A common theme among these technologies is their use of packetclassification at the ingress point where a data packet first enters adiscrete network (generally referred to in Internet terminology as anautonomous system). Conversely, the same packet will often bedeclassified at the egress point of that network so that the nextnetwork/autonomous system to receive the packet can, if it wishes,reclassify the packet in its own way. The classification ensures eachpacket receives the appropriate treatment when routed through a network.The treatment that a packet will receive as it passes through thenetwork will differ depending upon the type of classification given tothe packet at the ingress router.

For each classified packet, the intermediate routers coerce routing ofthe packet onto a different logical path through the network away fromthe predetermined default path that the packet would normally take if itwere unclassified. At least one default path is defined for each sourceand destination within the network. This default path is typically theleast-cost path as defined by the Interior Gateway Protocol (IGP) costmetric for each interconnection (described hereinafter in the context ofOSPF with reference to FIGS. 4-7).

A logical path is therefore an alternative non-default path taken by anypacket that receives different routing (packet forwarding) treatment. Alogical path may for example be a separate physical path from the onethat would typically be taken by the packet if it were unclassified.Similarly a logical path may be defined by different queuing treatmentat the intermediate routers. In either example, a classified packet willreceive a different set of treatments, depending upon the classificationreceived, giving the packet a different set of transmissioncharacteristics as compared to the same packet were it routed on thedefault path. Each logical path has a set of assigned properties thatdetermine the transmission characteristics for the packets that traversethe path, such as how much bandwidth on the physical interconnection isreserved for that logical path, the level of service (“bronze”, “silver”or “gold”), the maximum permissible jitter, or any specific routersthrough which the logical path must pass.

For example, a network operator applying traffic engineering may decideto transmit videoconference traffic that is sensitive to jitter via adedicated logical path through its MPLS-enabled network. That path isdifferent from other default paths which non-videoconference trafficwill take. Despite having potentially more router hops the dedicatedpath (in this case a separate physical path) carries no other trafficand can therefore easily accommodate the combined voice and video loadwithout introducing unwanted jitter. All other traffic takes the defaultpath, e.g. the route with the smallest overall cost metric as defined bythe IGP. Whichever route is taken, all traffic eventually arrives at theegress router and the packets are then declassified ready to be passedto the next network. Without this load balancing all network packetswould be routed using the default path and at peak times this may causethe network to become overloaded and discard or delay packets, makingthe videoconference unusable and causing problems for other data trafficusers.

The traffic-engineering process can be applied at many different levels,for example for different customers, for different services or forcombinations of both. Equally, other traffic-management tools such asQoS and SLA mechanisms that have different business objectives could beemployed. Both QoS and SLAs require packet classification at the ingressand egress points and both result in other routing policies and the useof logical paths that are different from the default (usually theleast-cost) path to route traffic concurrently within the network.

Many traffic-engineering techniques involve monitoring of the network'soperation, for example to audit conformance to agreed QoS or SLAcriteria and to trigger timely remedial action or (less desirably)compensation if the criteria are not attained. A problem for networkmanagement systems attempting such monitoring of traffic-managednetworks is to discover where packets enter and leave the network andwhether the classification and subsequent treatment of the packet iscorrect. The network management system should detect incorrect packetclassification which could cause traffic to be routed incorrectly, orfailure of an internal router which could cause all traffic to followthe same path irrespective of classification, in either case resultingin packets being delayed or discarded and perhaps breaching an SLA.

The overall Internet is divided into many administrative domains. Forexample, an Internet service provider might constitute a singleadministrative domain. Each administrative domain forms part of theInternet by entering into agreements with neighbouring domains (otherISPs etc.) to form peering or transit relationships to carry eachother's traffic and enable the connectivity expected by users. Anadministrative domain contains one or more autonomous systems (ASs). AnAS is a set of routers typically under a single technical administration(e.g. an ISP), which:

-   appears externally to have a single coherent interior routing plan    (using one and possibly several interior gateway protocols and one    or more common metrics to route packets within the AS);-   presents a consistent picture of what destinations are reachable    through it; and-   uses an exterior gateway protocol to route packets to other ASs.    Hereinafter the word “network” is used in the context of the    Internet to mean such an autonomous system. In the context of other    kinds of communications system the word network should be understood    as meaning an ensemble of operational elements which is analogous in    concept and functionality to an Internet AS, whether the ensemble    comprises the whole of the system or only part thereof.

The Internet consists of many ASs in many administrative domains. Ateach connection between each AS there are “edge” routers and each edgerouter has the potential to implement some form of traffic management. Alarge ISP may have many ingress and egress routers interacting with manyother ISPs and have many different end customers. Each ingress andegress router could be classifying and routing traffic using manydifferent policies. The enormous challenges involved in deploying,monitoring and managing traffic-management technologies is readilyapparent.

Having knowledge of the overall topology of the network (e.g. theidentity of active edge routers and of intermediate routers which handlea packet traversing the network) is of considerable assistance inmeeting these challenges. However, existing packet network technologiesdo not provide this knowledge in an explicit form that is easilyaccessible to external tools that could be used to facilitate trafficmanagement. A system supplementary to the network itself that couldassist in the challenges described would require topological informationto be delivered from a potentially very large network in near real timeand ideally without discernable impact upon existing network and routerperformance. Routers typically contain a complete database of router andlink status in the network. This information is known as the link statedatabase and is used to generate a routing table within each router todetermine the optimum neighbouring router to which to forward a datapacket towards its ultimate destination. The routing table is generatedfor example by means of the OSPF link-state protocol described in RFC2328 (and referred to hereinafter as the OSPF protocol). The informationcontained within the router's link-state database describes the topologyto an extent sufficient for that router's operational requirements; suchdata could in principle be extracted piecemeal from the routers and beexploited to produce a complete topology description. Unfortunately,using current technologies the required data it is not accessible in amanner that satisfies the necessary requirements of scale, accuracy andtimeliness whilst ensuring that network integrity is maintained.

For example, although queries using the Simple Network ManagementProtocol. (SNMP) could in theory be used to gather the requiredinformation, this approach is not well suited to use with large networkscontaining multiple routers. The large set of SNMP queries required whendetermining a complete topology for a network would place a largeprocessing burden upon the routers and generate a substantial volume ofnetwork traffic. Furthermore, to avoid having to query each address on anetwork, most of which will be terminals such as personal computers orworkstations, the router addresses would need to be known in advance,imposing a substantial administrative burden and compromising thebenefits of autonomous discovery or verification of the networktopology. Similar problems apply to extracting information from anoperation support system (OSS) or other external data source; thisinformation may not be available, may not be provided, or may be deemedtoo sensitive to permit retrieval via direct access. Furthermore, evenif the information were available there is no guarantee, withoutindependent verification, that the information is accurate.

It is an object of this invention to facilitate the monitoring oftraffic management, by assisting with the provision of descriptions ofnetwork topology. For example, a network topology description obtainedby using the invention can assist network operators to administernetworks deploying traffic management techniques such as MPLS andDifferentiated Services, or can be used in deploying core MPLS-enabledIP networks (see RFC 2917), Voice over IP services (also known asInternet Telephony), SLAs and QoS mechanisms. In particular theinvention facilitates monitoring of the different logical paths and anyassociated transmission characteristics implemented over the variousphysical interconnections, routers and sub-networks present in thenetwork.

DISCLOSURE OF INVENTION

According to one aspect of this invention there is provided a method foridentifying a network-wide set of paths potentially taken by packets ina communications network, comprising the steps of:

collecting packets containing information indicative of theinterconnection of the network, and of its interconnection with othernetworks;

detecting the contents of the collected packets;

using the detected contents to identify the network-wide set of routersand sub-networks and their interconnections, that are traversed bycommunications within the network; and

providing an output indicative of any selected part of the network-wideset of routers and sub-networks and their interconnections.

“Network-wide” in this context means that the network descriptionproduced is not focused on any particular router or other node in thenetwork. OSPF for example notionally produces in each router a treedescription of paths through the network, with that router as the rootof the tree, as a transient step towards generating a desired routingtable. Paths between routers that are not needed to forward packets fromthis “root” router are not included in the tree. In contrast, thepresent invention generates a description of the network topology inwhich all routers are equally significant, and in a typicalimplementation provides a comprehensive view of all paths, not just thedefault path, between all routers.

According to another aspect of this invention there is providedapparatus for identifying a network-wide set of paths potentially takenby packets in a communications network, comprising:

a collector for collecting packets containing information indicative ofthe interconnection of the network, and of its interconnection withother networks;

a detector for detecting the contents of the selected packets;

an identifier for using the detected contents to identify thenetwork-wide set of routers and sub-networks and their interconnections,that are traversed by communications within the network; and

an output for providing an indication of any selected part of thenetwork-wide set of routers and sub-networks and their interconnections.

BRIEF DESCRIPTION OF DRAWINGS

A method and apparatus in accordance with this invention, foridentifying functionality of routers interconnected by communicationslinks in a communications network, will now be described, by way ofexample, with reference to the accompanying drawings, in which:

FIG. 1 shows a notional fragment of the Internet;

FIG. 2 shows an illustrative network topology description;

FIGS. 3 to 7 show the format of link state advertisements as defined inthe OSPF protocol;

FIGS. 8 to 13 show a procedure for deriving a network topologydescription; and

FIG. 14 shows the notional fragment of FIG. 1 after failure to tworouters within it.

DETAILED DESCRIPTION

Referring to FIG. 1, a notional fragment of the Internet is showncomprising an autonomous system AS1 and portions of two other autonomoussystems AS2 and AS3 connected to it. The system AS1 contains two edgerouters 10 and 12 which provide external connections, to the systems AS2and AS3 respectively, and three internal routers 14, 16 and 18 which areconnected solely to other routers within their own AS. The systems AS2and AS3 likewise include edge routers 20 and 30 respectively, providingconnection to the system AS1, as well as internal routers 22, 24, 30 and34.

Each AS requires forwarding information, both local to the AS and globalbetween ASs, so that data packets can be routed through the nodes orrouters to the correct destinations. Between ASs the routers (androutes) are configured either statically or dynamically using a class ofprotocols called Exterior Gateway Protocols, e.g. the Border GatewayProtocol (BGP) described in RFC 1771. Within an AS the routers (androutes) are configured either statically or dynamically using a class ofprotocols called Interior Gateway Protocols (IGPs), such as OSPF, IS-ISor Routing Information Protocol (RIP). For convenience the followingdescription will assume the use of OSPF, but the invention can be usedin association with other protocols embodying analogous concepts andfunctionality to OSPF, including IS-IS.

In a link-state routing protocol such as OSPF each router is responsiblefor distributing and maintaining a database describing the topology ofan area or zone forming the whole or part of the AS containing thatrouter. This database is known as the link-state database. On start up,the router is only aware of its own local state, its connectedinterfaces and networks in accordance with information that ispre-configured by the router's administrator. The process of learningand distributing further network state information, such asconnectivity, is achieved by exchanging special data packets defined bythe OSPF protocol with other routers within the AS.

Initially “adjacencies” are formed with neighbouring routers using, forexample, packet multicast techniques. An adjacency is a relationshipform-ed with each of a router's active neighbours for the purpose ofexchanging routing information. Once an adjacency has been formed theadjacent routers exchange information about their state using OSPFlink-state description packets formatted in accordance with theprotocol. This process continues until both routers share a common viewof the topology of their zone of the AS, thereby building a link-statedatabase in each router.

On completion of the adjacency forming process throughout the AS, eachrouter in the AS executes the same algorithm in conjunction with its owncopy of the link-state database, to construct a unique routing tablecomprising a tree of least-cost paths, as defined by the IGP metric,from itself as root to each destination. The resultant least cost pathsbecome the default routes taken by all unclassified packets traversingthe network.

As noted above, sets of networks within the AS can be grouped togetherinto routing areas or zones. The topology of a zone is not shared withthe rest of the AS containing that zone, to provide a significantreduction in routing traffic. Between zones summary packets areexchanged to ensure inter-zone connectivity.

After the initial generation of its link-state database and routingtable, each router repeats the information exchange and routecalculation process if a change in its network zone occurs. A changemight involve the addition or removal of a link or router, or a changein a link's costs. To avoid the possibility of the link-state databasebecoming stale the packets are, in the absence of new updates,re-broadcast periodically, normally every thirty minutes.

The invention implements non-intrusive discovery of the network topologywithin an AS using a link-state IGP such as OSPF or IS-IS, and creationof an annotated representation of that topology to facilitate thesubsequent discovery of a network-wide set of paths through thatnetwork. The annotated representation describes the AS by means of adirected graph, in which vertices represent routers or networks andedges represent links connected to the routers. The annotations indicatediscovered data about the router or network represented by each vertex.In the case of routers the annotations indicate associated IP address, aset of interfaces denoted by IP address, and type or function(intra-zone, inter-zone or inter-autonomous system). For networks theassociated network addresses and netmask, denoted by IP address, andnetwork type (stub, transit or external) are shown. Transit networks arethose capable of carrying data traffic that is neither locallyoriginated nor locally destined. Stub networks are analogous tocul-de-sacs and external networks are destinations to other networksoutside the AS.

A visual representation of an example of a graph produced in accordancewith the invention is shown in FIG. 2. The edges of the graph connectthe individual vertices. An edge connects two routers when they areattached via a physical point-to-point link whilst an edge connecting arouter to a network indicates that the router has an interface on thenetwork. Each edge is annotated with the cost of using that interfacefor packet forwarding, as defined by the IGP. In OSPF this is known asthe link metric.

One aim of the invention is to generate a topology with limited impactupon the normal operation of the network or the routers. The topologydiscovery process is non-intrusive in the sense that the requiredinformation is obtained by means of limited active interaction with therouters or other network elements and without generating significantadditional network traffic. To this end and as shown in FIG. 1 at leastone probe or monitor 40 is connected to the AS at a point where the OSPFpackets are present. The probe could for example be a low-cost computer,such as a “personal computer”, running a dedicated software program andconnected to the AS via an Ethernet card. The “logical” point ofconnection to the network is chosen to ensure that OSPF packetsbroadcast by the routers can be collected. Physically, this connectionpoint may be, for example, a port on a router, or a tap into a linkbetween two routers, from a sub-network via a hub or switch. In OSPFterms a connection is required at any point in the network traversed byOSPF packets. For these physical connections the software program in theprobe 40 opens a connection in “promiscuous mode” onto the network linkor segment of the chosen network zone. Promiscuous mode allows the probeto receive the required OSPF packets irrespective of their LANdestination address. The received packets are allowed to continue theirjourney through the network without interference (rather than beingreceived and removed from the network). Alternatively, OSPF and otherIGP routing packets are also stored by the routers themselves in theirown LSDBs and are available in raw byte format via the SNMP MM fordebugging purposes. Initially, and at each subsequent change intopology, the packets can also be collected from the OSPF MIB withlimited network impact and overhead. Collection of the raw packets froma MIB requires a very low number of SNMP calls, rather than the multipleSNMP calls that are a feature of the existing methods of using SNMP.Changes to the MIB data can be tracked using SNMP traps. A SNMP trap,once set, will inform an external application of a change in the targetMIB data.

The probe 40 does not implement a state machine as described in RFC 2328to establish an adjacency with any router, as that would require theprobe to become an active participant in the OSPF routing protocol,thereby creating spurious link-state database entries in that zone'sother routers. For collection of the packets by monitoring a link theprobe 40 remains passive and relies on the flooding process of OSPFpackets by the routers in the zone or AS. The probe 40 waits for OSPFpackets to arrive on the monitored interface, rather than requestingthem using the normal OSPF mechanisms. A topology derivation procedure(described below and illustrated in FIGS. 8 to 13) is executed upon thereceipt of every OSPF packet, to build up the desired topologydescription incrementally. The start-up procedure requires the defaultlink-state refresh interval, normally thirty minutes, to have elapsedbefore a complete topology description is determined. Becoming an activeparticipant in the OSPF protocol can accelerate the collection of thepackets and reduce the time for the complete discovery process;obviously a side effect in this case is the increased impact upon thenetwork and the routers. Alternatively, where the probe 40 collects OSPFrouting data from raw packets contained within the MIB, a complete andup-to-date topology can be obtained with no start-up period required.This method also limits the impact upon the routers or network.Thereafter by continuing to track the OSPF packets the probe can keepthe topology description in step with the state of the network.

The number of probes required for an AS depends upon the size of the ASand how it is organised. A single probe can generate a completeannotated topology for the zone to which it is connected. An OSPFnetwork always has at least one zone, which is known as the backbone.Connection to this backbone is preferred. Experience indicates that manynetworks are hierarchical in design and a single probe connected to thebackbone will provide a very useful annotated topology. To discover acomplete annotated topology for a multi-zone AS, a connection to eachactive zone is required. However, even a single connection will provide,in addition to the complete annotated topology of the chosen zone,summary information for the networks in other zones in the AS, plus anyconnections to external networks via the AS's edge routers.

Each probe 40 collects the packets and makes copies of selected types ofpackets described below. It then extracts data from these copies andprocesses the data to yield information for the annotated topology.

Five types of packet are defined in the OSPF protocol, as shown in thefollowing table. For the purposes of the present invention one of theseOSPF packet types is used, the Link State Update packet, type 4. TypeDescription 1 Hello 2 Database Description 3 Link State Request 4 LinkState Update 5 Link State Acknowledgement

Hello packets are also present on OSPF networks, for example onbroadcast media such as Ethernets, and are transmitted most frequently,appearing at regular intervals on a given network segment. Hello packetscan therefore be used to supply the probe 40 with an accurate indicationof network time. An accurate time stamp is applied to Hello packets ontheir arrival at the probe. For example, a probe based upon a personalcomputer could obtain an accurate indication of time either from itsinternal clock or from a Global Positioning System (GPS) receiver inconjunction with the Network Time Protocol (NTP). Experience has shownthat most network operators provide an accurate time service that can beused for this purpose. By measuring the inter-interval time of the Hellopackets and storing the result an accurate internal representation ofthe passage of time driven by the normal OSPF packet sequence can beestablished. This form of timer mechanism is a convenient way ofproviding a timebase for ensuring obsolete information is purged fromthe probe 40. However, any other form of timer mechanism that canprovide an accurate indication of passage of time will suffice.

The Link State Update packets (OSPF type 4) contain one or more LinkState Advertisements (LSAs), which describe the state of either a router(including the state of the router's interfaces and adjacencies) or anetwork. The collection of LSAs for a zone comprises the link-statedatabase. Several types of LSA exist, as shown below, and each LSA typedescribes a different element within the AS or network zone. LS TypeDescription 1 Router-LSAs 2 Network-LSAs 3 Summary-LSAs (IP network) 4Summary-LSAs (ASBR) 5 AS-external-LSAs

LSAs are broadcast whenever a change in the network configurationoccurs, and at regular intervals to ensure that stale information is notpresent in the network. Each LSA has a header portion (shown in FIG. 3)that contains both a key (comprising a combination of fields in theheader) and age information that give a unique identity to the LSAwithin the AS. The process of determining if an LSA should be acceptedinto the link-state database is described in RFC 2328, sections 13.1 and13.2, and is used by the probe 40 to determine if an LSA it receives isnewer than an existing LSA that it already has, and whether that LSAshould be accepted into its own link-state database.

As the probe's internal clock is updated the new time value is used toincrement the age field of every LSA in the link-state database. If anLSA's age value thus becomes greater than the OSPF standardarchitectural constant MaxAge, conventionally set to one hour, the LSAis removed from the link state database (as shown in FIG. 8). Thisprocess provides a safeguard ensuring that stale LSAs are removed fromthe probe's link-state database, so that if an updated LSA is missed bythe probe or lost due to a temporary link failure, the topologydescription provided by the probe 40 will not be unduly corrupted.

When the probe has first assembled its link-state database, and aftersubsequent changes in the probe's link-state database are detected tohave occurred (e.g. following receipt of a new or updated LSA), theprobe's annotated description of the current network topology must becreated or refreshed. The procedure for accomplishing this will now bedescribed, with reference to FIGS. 8 to 13. The precise sequence of mostof the steps involved is not critical, although step 6 must be performedlast. Equally, the topology could be entirely re-calculated for everylink-state database change, or just incrementally in respect of the mostrecent LSA changes processed. Both approaches are equally valid and themethod that proves simpler to implement or more appropriate in aspecific implementation can be chosen. In the example described belowidentifying the vertices of the topology first is convenient andconforms to normal graph construction techniques.

Step 1 (FIG. 9): Identify the active sub-networks within the zone andthe active routers in those sub-networks; this is accomplished using theLSAs that contain information about the network elements within thecurrent zone, specifically Type 2 Network-LSAs and a subset of Type 1Router-LSAs. Network-LSAs specify the routers that are attached to asub-network that supports more than one router. The Network Mask fieldin a Network-LSA (see FIG. 5) describes the size, or range, of theaddress space of the sub-network, and the IP address in the Link StateIdentifier field of the LSA's header (FIG. 3) identifies the first IPaddress in the sub-network. Lists of active routers on that sub-networkare also provided, the routers being denoted by IP address in theAttached Router field (FIG. 5). Each LSA contains one entry for each andevery active router on the sub-network.

Router-LSAs can be sub-divided depending upon the type of link beingdescribed, and each Router-LSA may describe several links of differenttypes. The types of connections are identified as follows: TypeDescription 1 Point-to-point connection to another router 2 Connectionto a transit network 3 Connection to a stub network 4 Virtual linkOnly those Router-LSAs containing information on type 3 links to a stubnetwork are considered in this step. For each Router-LSA describingconnections to stub networks, each Link Identifier field (FIG. 4) andthe following Link Data field give the IP address and network mask for aconnection to a stub network on the router identified by the AdvertisingRouter field of the LSA's header. If the penultimate router on asub-network fails so that the sub-network no longer has two or morerouters the corresponding Network-LSA may not be actively withdrawn fromthe link-state database. In this situation although the Network-LSA isstill present, it is superseded by a new type 3 Router-LSA containing anentry describing a connection to a stub network. Therefore, in order toensure only active routers on active sub-networks are considered in thisstep, the information contained in these two types of LSAs are combinedso that a router defined by an entry in a type 3 Router-LSA takesprecedence over information about the same router defined in a NetworkLSA.

Step 2 (FIG. 9): Specify the topology's internal network vertices. Avertex is created for each active network in the list of activesub-networks derived in step 1. The vertex is annotated with the EPaddress and the network mask thus specifying the identity and addressrange of the sub-network- represented by the vertex. These vertices arealso annotated with the type ‘internal network’.

Step 3 (FIG. 9): Specify the topology's router vertices and theirassociated interfaces:

Step 3.1: The type 2 Router-LSAs containing entries describing theconnections to transit networks are analysed. These LSAs describerouters that have connections to sub-networks that have more than oneentry/exit point. For each LSA the IP address of the router, identifiedby the Advertising Router field in the LSA's header, is added to thelist of vertices. A list of active router interfaces identified by theIP address in the Link Data field is associated with the vertex entry.In this context an interface on a router is a synonym for the port towhich a network connection or link is made.

Step 3.2: The type 1 Router-LSAs containing entries describing linksthat are point-to-point connections are analysed. As before the routerIP address is added to the list of vertices and the IP addresses of therouter's interfaces identified by the Link Data field are also added.

Step 3.3: A similar process is employed for the type 4 Router-LSAscontaining entries describing virtual links (virtual links are describedin RFC 2328, sections 3.1 and 15).

Step 3.4: Next the type 3 Router-LSAs, containing information aboutconnections to stub networks, are analysed. The process is the same asthat for type 2 Router-LSAs containing entries describing theconnections to transit networks. However, in this case the routeraddress itself is added as the associated router interface. The LinkData field for this type of Router-LSA entry does not describe therouter's interface, but describes the network mask of the connected stubnetwork. The IP address interface for the router's interface cannottherefore be determined. For the purposes of specifying the connections,as described later, the start point for this type of link is consideredto be the router itself.

Step 3.5 (FIG. 10): The specified router vertices are annotated withtheir associated types. The router types are marked according to the Eand B flags in the VEB field of the Router-LSA (FIG. 4). If the B flagis set then the router is marked as inter-area; if the E flag is set therouter is marked as inter-AS or inter-network; otherwise the vertex ismarked as intra-area. If the V flag is set the vertex is the end-pointfor one or more virtual links.

Step 3.6 (FIG. 11): For each ASExternal-LSA a router vertex is added, ifit does not already exist, as identified by the Advertising Router fieldof the LSA header, with an associated interface as identified by the IPaddress in the ‘Forwarding Address’ field (FIG. 7). The vertex isannotated as an ‘inter-AS router’. Similarly, for each Summary-LSA acheck is made that a vertex exists for the router identified by the IPaddress in the Advertising Router field, and that it is annotated asbeing an ‘intra-area router’. This step has two purposes: to check theintegrity of the data and to speed the discovery process on probestart-up, during the period where a complete topology has not yet beencollected.

Step 4.1 (FIG. 12): Specify the topology's inter-area network vertices.For this the type 3 and type 4 Summary-LSAs are considered. These LSAsdescribe connections to inter-area destinations comprising eithernetworks (for type 3 Summary-LSAs) or inter-area routers (for type 4Summary-LSAs). For each Summary-LSA, of either type, a network vertexidentified by the IP address Advertising Router field and the NetworkM4ask field (FIG. 6) is added to the list of vertices. These verticesare annotated with the type ‘summary network’.

Step 4.2 (FIG. 12): Specify the topology's inter-AS network vertices.The type 5 ASExternal-LSAs are used to specify a set of externalvertices that represent routes to networks external to the networkcontaining the probe 40. These are routes whose existence has been madeknown via either pre-configured static route descriptions or via anExterior Gateway Protocol such as BGP-4. For each of these externalroutes the OSPF routers will issue an ASExternal-LSA. For each LSA avertex is added to the vertex list for the network identified by the IPaddress in the Link State Identifier field of the LSA's header and theNetwork Mask (FIG. 7). The vertex is annotated with the type ‘externalnetwork’.

Step 5 (FIGS. 12 and 13): Specify the edges in the network:

Step 5.1: Specify the transit edges. Type 2 Router-LSAs containingentries describing connections to transit networks are used to specifyedges in the graph that interconnect vertices representing routers toany vertices representing networks that offer a through or transitservice. (A transit network is one that has two or more separateentry/exit points.) For each Router-LSA containing an entry thatdescribes a transit connection to a network, an edge is specified in theevolving topology description from the router interface defined in theLink Identifier field (FIG. 4) to the sub-network defined by the LinkData field. (According to RFC 2328 “when connecting to an object thatalso originates an LSA (i.e., another router or a transit network) theLink Identifier is equal to the neighbouring LSA's Link StateIdentifier”.) Therefore the sub-network with the correspondingNetwork-LSA ‘Link State Identifier’ is used to determine the endpointfor the edge being specified. The edge is annotated with the cost oftraversing the link as defined in the Metric/Cost field. It is importantto note that there could be more than two edges connected to thesub-network vertex.

Step 5.2: Specify the stub edges. Router-LSAs containing entries thatdescribe connections to stub networks are used to specify edges betweenthe relevant router vertices and network vertices with only one entryand exit point. For each type 3 Router-LSA containing an entry thatdescribes a connection to a stub network, an edge is added starting atthe router's interface; in this instance the interface has the sameaddress as the router itself (in effect addressing the router directly)and ending at a sub-network. The edge start is denoted by the AdvertingRouter field and the destination is the sub-network as defined by theLink Identifier and Link Data fields. The sub-network address is denotedby the IP address in the Link Identifier field and the network mask bythe Link Data The edge is annotated with the cost of traversing the linkdefined in the Metric/Cost field.

Step 5.3: Specify the point-to-point edges. Router-LSAs describingpoint-to-point and virtual links are used to specify edges that directlyinterconnect router vertices. Virtual links are described in RFC 2328sections 3.1 and 15 and for the purposes of generating a topology theycan be handled in the same way as point-to-point links. For eachRouter-LSA containing entries that describe either point-to-pointconnections to another router, type 1, or virtual links, type 4, an edgeis added to the evolving topology. The edge starts at the routerinterface denoted by the IP address in the Link Data field and thedestination router denoted by the IP address in the Link Identifierfield. The edge is annotated with the cost of traversing the linkdefined in the Metric/Cost field.

Step 5.4: Specify the inter-area edges. Summary-LSAs are used to specifyedges connecting router vertices to vertices describing any inter-areadestinations. There are two types, type 3 which describe destinationsthat are IP networks and type 4 which describe destinations that areother inter-area routers. For each type 3 Summary-LSA an edge is addedfrom the router's interface (in this instance having the same address asthe router itself, ill effect addressing the router directly) to theinter-area sub-network as defined by the Link State Identifier field andthe Network Mask field. For type 4 Summary-LSAs the Network Mask fieldis not meaningful and must be zero, and the Link State Identifier is theIP address of the inter-AS router. In both cases the edge is annotatedwith the cost of traversing the link as defined in the Metric/Cost field(FIG. 6).

Step 5.5: Specify the inter-AS edges. ASExternal-LSAs are used tospecify edges connecting router vertices to vertices describing anyexternal destinations outside the AS. For each ASExternal-LSA an edge isadded from the router interface denoted by the Forwarding Address field(FIG. 7) to the external network defined by the Link State Identifierfield in the LSA's header and the Network Mask field (FIG. 7). The edgeis annotated with the cost of traversing the link defined by the E bitfield and the Metric/Cost field. If the E-bit is unset then the metric,or cost, is defined in the same units as the other internal link metricsof the other edges. If the E-bit is set then the cost of the link isconsidered larger than any other internal link- state path.

Step 6 (FIG. 13): Maintain a graph of viable paths. The probe 40 musteliminate any out-of-date information, thus ensuring that only viablenetwork paths are reported to a traffic-management or other applicationusing the topology information. For example, there is a possibility thatthe probe's link state database may contain LSAs that arrived prior to anetwork outage or failure that caused a partition in the network. FreshLSA updates from any router that resides on the network on the far sideof the partition failure point will not have been able to reach theprobe 40 where they would be used to remove the stale information. Tomaintain an accurate topology description the probe 40 must eliminatethe vertices and edges representing affected routers, networks andlinks.

For example, in the scenario of FIG. 1 the routers 16 and 18 might crashowing to a power failure. FIG. 14 shows the resultant networkconfiguration. The probe 40 will continue to receive updates from therouters 10 and 14 on its side of the failure or ‘network partition’.However the router 12 lying beyond the partition cannot communicate thechange to either of the routers 10 and 14. Consequently the link-statedatabases in the routers 10 and 14 and the probe 40 will continue tocontain LSAs sent from router 12. However the information in these LSAscan no longer be considered reliable as it is from outside the probe'scurrent known routing zone. The purpose of the probe 40 is to create adescription of all possible and viable network paths, so thisdescription should not include portions of the network beyond the pointwhere the failed routers 16 and 18 are situated.

The reach-ability of each vertex in the graph is assessed bysystematically inspecting all the vertices using a recursive procedurestarting at the vertex representing the point where the probe 40 isconnected to the network. There are a number of well-known proceduresfor determining reach-ability in graphs based upon, for example,‘breadth first search’ and ‘depth first search’ algorithms. Only theconnected edges to each vertex are considered in these algorithms so thedisconnected portion of the graph, in this example routers 16 and 18,will be eliminated and the result is a ‘connected graph’ eliminatingpaths from router 12 to router 30 and beyond from the results.

It is important to note that the start vertex for the recursivealgorithm could either be a router or a network depending upon whichelement is logically closest to the probe 40. For example, if the probeis connected directly via a tap on a point-to-point connection then thestart point is the logically nearest router. Or, if the probe isconnected on a transit sub-network then the sub-network should be used.If the probe is connected to the MIB on a router then the router shouldbe used. A transit sub-network provides multiple reachable connectionsto the overall network-via each of its connected routers, and thesemultiple connections must be considered during any reach-abilitycalculations. The resultant graph can be exported to an externalapplication (e.g. for traffic management) and includes only the activeinterconnected vertices currently known to the probe 40.

The graph can be exported by the probe 40 to one or more externalapplications via an appropriate form of inter-process communication. Forexample, the known Remote Procedure Call mechanism (RPC) or themechanisms described in standards for Common Object Request BrokerArchitecture (CORBA) or Java Remote Method Invocations (RMI) may beused. The software for the probe 40 could also be embedded directly intoapplication software to create a simple, small, lightweight, portablesystem that could be transported around the network by the operator asrequired.

The annotated graph data could be made available so that an applicationis made aware of each change as it occurs. This is sometimes referred toas a ‘publish and subscribe’ mechanism whereby the applicationsubscribes to the changes as they are published. Alternatively, and moresimply, a new topology could be delivered to an application on demand.

The exported topology information could take several forms but willinclude some type of listing of the active vertices and active edges.The listing of active vertices typically includes: the vertex identitydenoted by the IP address and network mask or prefix length; the type ofnetwork element represented by the vertex, for example, network,inter-AS, inter-zone and intra-zone, and the intra-zone and the zone towhich they belong. Also included could be the list of interfaces,denoted by IP address. The list of edges typically includes the verticesto which they are connected, denoted by IP address and network prefixand the cost or metric of using the link represented by the edge. Alsoincluded in the list of edges could be the interface used on the router,also denoted by IP address.

If an application requests changes as they occur, using a ‘publish andsubscribe mechanism, then edges and vertices that become inactive or anetwork- change can be removed from the topology description byspecifying the vertices in terms of EP address and network prefix.Similarly edges to be removed can be identified in terms of the twoconnecting vertices. When informing the application that an edge orvertex is no longer active the annotation information, such as edgemetric or vertex type, can also be supplied but is not strictlynecessary.

An application makes use of the annotated graph data to determine theset of current active logical paths by, for example, extracting a listof those vertices providing any inter-AS connectivity. Vertices of thistype comprise the ingress and egress points of the network and are themost likely places where traffic classification would be applied asdescribed above. The application can directly query the routersrepresented by those vertices to determine if in fact trafficclassification is present; one common mechanism that could be used forsuch a query is SNMP (RFC 1157). SNMP and the associated ManagementInformation Bases (MIBs) for the chosen traffic management systems areavailable on the majority of routers and provide a widely acceptedmechanism for access to this type of network management data. Theinternal router vertices could also be searched if there is a likelihoodof any internal traffic classification being present on the network.This is less likely but in some situations may occur.

If traffic classification is being used, for example, to route thetraffic from a given provider along a path other than the defaultleast-cost path, via an MPLS Label Switched Path (LSP), the externalapplication can request that the router return information about theactual non-shortest path currently in use. SNMP again can be used toretrieve this path information including any transmissioncharacteristics, for example the reserved bandwidth, that have beenassigned to the logical path.

The discovered topology data can be used to determine the network-wideset of paths, including the set of default paths for the topology. It isimportant to note that multiple logical paths from different sourcerouters may potentially traverse a single interconnection. As aconsequence the network-wide set of paths must be considered whendetermining alternative logical paths. Failure to consider thenetwork-wide set of paths may lead to over-specification and congestionon a router, sub-network or interconnection that services multiplelogical paths from different source/ingress routers. The network-wideset of paths is required to ensure the validity of these calculations.To determine this set of paths use is made of recursive procedures forperforming traversal of a graph based upon ‘breadth-first search’ or‘depth first search’ and Dijkstra's algorithm (described in RFC 2328);these provide the set of network-wide paths, including the shortestpaths, for each combination of ingress/source and egress/destinationrouter. The inputs to the algorithms are the IGP cost metrics and thediscovered graph data about the routers, sub-networks andinterconnections.

The network operator can, for example, use the combined information,including the set of network-wide paths and their associatedcosts/metrics through the AS, in conjunction with the overlaid requestedtraffic management information (about the LSP) to monitor the logicalnon-default path deployment. This combined information provides avaluable aid to the network operator, for example in designing newpaths, LSP provisioning, and ensuring that the network is performing todesign specification.

For example, by comparing the network-wide paths, the default paths, theactive logical paths and the routing objectives associated with theactive paths it is possible to generate a set of alternative logicalpaths that would conform to the routing objectives associated with theactive logical paths. Referring to FIG. 1 (and assuming for simplicityin this example that the IGP path cost is analogous to the number ofrouters traversed and that all links have an equal maximum capacity),the application will calculate that the default path from the router 10to the router 12 is via the router 18. An active MPLS LSP is discoveredbetween the routers 10 and 18 that requires a reserved bandwidthequating to 75% utilisation of the link maximum capacity. This LSP hasbeen installed at the request of the manager of AS3 who requires aguaranteed level of bandwidth for connection to AS2. A second path isalso discovered between the routers 10 and 12 via the routers 14 and 16,that is being used for another purpose; this path requires 20% of thebandwidth on those links. The application determines that the first LSPis on the default path, and that the combined load of the first andsecond LSPs does not equate to more than the available maximum capacity.The application can therefore recommend that an alternative path for thefirst LSP would be via the router 14 and the router 16, rather than viathe default path through the router 18.

Utilising a mechanism to inform the external application of any changeto the LSP, for example caused by loss of an internal transit networkowing to link failure, may help the operator to mitigate the impacts ofsuch a failure by providing an immediate warning of the LSP change. Onesuch mechanism that allows routers to provide feedback is the SNMP trapmechanism. An SNMP trap, once set, will inform an external applicationof a change in the target MIB data. The new LSP, or any changes to thecharacteristics of the LSP, can then be overlaid over the changedtopology once again providing near-real time feedback of LSP behaviour.

The annotated topology provided by the probe 40 is therefore able toassist operators in various network management tasks including thosedescribed above. The described process could also be applied, but is notlimited to, other forms of traffic management and other technologiesthat employ routing over separate logical paths via packetclassification at ingress and egress routers, as alternatives to typicalleast-cost path routing, such as Differentiated Services, VirtualPrivate Networks (VPNs), Voice over IP, SLAs and QoS mechanisms.

1. A method for identifying a network-wide set of paths potentiallytaken by packets in a communications network, comprising the steps of:collecting packets containing information indicative of theinterconnection of the network, and of its interconnection with othernetworks; detecting the contents of the selected packets; using thedetected contents to identify the network-wide set of routers andsub-networks and their interconnections, that are traversed bycommunications within the network; and providing an output indicative ofany selected part of the network-wide set of routers and sub-networksand their interconnections.
 2. The method of claim 1, including the stepof using the detected contents to determine the functionality associatedwith the identified routers and sub-networks, and metrics of theidentified interconnections, which are traversed by communicationswithin the network.
 3. The method of claim 2, including the step ofusing the detected contents to determine a network-wide set of potentialpaths, both through the network and connecting the network with othernetworks, which are traversed by communications within the network. 4.The method of claim 3, including the step of using the detected contentsto determine a set of default paths, as defined by the cost metrics,which are traversed by communications within the network.
 5. The methodof claim 3, including the steps of: querying the routers based upontheir predetermined functionality; and using the results of the queryingto determine if packet classification is occurring at network ingressrouters and if any alternative logical paths to the default path aretraversed by communications within the network.
 6. The method of claim3, including the step of using the detected contents to determinealternative logical paths that could be traversed by communicationswithin the network.
 7. (canceled)
 8. The method of claim 5, includingthe step of querying the routers for properties associated with thedetermined paths that are indicative of predetermined routing objectivesfor the paths. 9-11. (canceled)
 12. Apparatus for identifying anetwork-wide set of paths potentially taken by packets in acommunications network, comprising: a collector for collecting packetscontaining information indicative of the interconnection of the network,and of its interconnection with other networks; a detector for detectingthe contents of the selected packets; an identifier for using thedetected contents to identify the network-wide set of routers andsub-networks and their interconnections, that are traversed bycommunications within the network; and an output for providing anindication of any selected part of the network-wide set of routers andsub-networks and their interconnections.
 13. The apparatus of claim 12,wherein the identifier uses the detected contents to determine thefunctionality associated with the identified routers and sub-networks,and cost metrics of the identified interconnections, which are traversedby communications within the network.
 14. The apparatus of claim 13,wherein the identifier uses the detected contents to determine anetwork-wide set of potential paths, both through the network andconnecting the network with other networks, which are traversed bycommunications within the network.
 15. The apparatus of claim 14,wherein the identifier uses the detected contents to determine a set ofdefault paths, as defined by the cost metrics, which are traversed bycommunications within the network.
 16. The apparatus of claim 14,including a query generator for querying the routers based upon theirpredetermined functionality, wherein the identifier uses the results ofthe querying to determine if packet classification is occurring atnetwork ingress routers and if any alternative logical paths to thedefault path are traversed by communications within the network.
 17. Theapparatus of claim 14, wherein the identifier uses the detected contentsto determine alternative logical paths that could be traversed bycommunications within the network.
 18. (canceled)
 19. The apparatus ofclaim 16, wherein the query generator queries the routers for propertiesassociated with the determined paths that are indicative ofpredetermined routing objectives for with the paths. 20-22. (canceled)23. The method of claim 4, including the steps of: querying the routersbased upon their predetermined functionality; using the results of thequerying to determine if packet classification is occurring at networkingress routers and if any alternative logical paths to the default pathare traversed by communications within the network; and generating acomparison between the determined paths.
 24. The method of claim 23,including the steps of: querying the routers for properties associatedwith the determined paths that are indicative of predetermined routingobjectives for the paths; and using the comparison to determinealternative logical paths to those currently in use that would meet thepredetermined routing objectives.
 25. The method of claim 4, includingthe steps of: using the detected contents to determine alternativelogical paths that could be traversed by communications within thenetwork; and generating a comparison between the determined paths. 26.The method of claim 25, including the steps of: querying the routers forproperties associated with the determined paths that are indicative ofpredetermined routing objectives for the paths; and using the comparisonto determine alternative logical paths to those currently in use thatwould meet the predetermined routing objectives.
 27. The method of claim5, including the steps of: using the detected contents to determinealternative logical paths that could be traversed by communicationswithin the network; and generating a comparison between the determinedpaths.
 28. The method of claim 27, including the steps of: querying therouters for properties associated with the determined paths that areindicative of predetermined routing objectives for the paths; and usingthe comparison to determine alternative logical paths to those currentlyin use that would meet the predetermined routing objectives.
 29. Themethod of claim 4, including the steps of: querying the routers basedupon their predetermined functionality; using the results of thequerying to determine if packet classification is occurring at networkingress routers and if any alternative logical paths to the default pathare traversed by communications within the network; using the detectedcontents to determine alternative logical paths that could be traversedby communications within the network; and generating a comparisonbetween the determined paths.
 30. The method of claim 29, including thesteps of: querying the routers for properties associated with thedetermined paths that are indicative of predetermined routing objectivesfor the paths; and using the comparison to determine alternative logicalpaths to those currently in use that would meet the predeterminedrouting objectives.